Prior to the development of object-oriented programming, a form of programming was developed known as structured programming, which is still used extensively. In this technique, various functions are first defined, and the program then consists of calling such defined functions at appropriate times to effect the overall objective of the application program. Structured programming provided the opportunity of a modularized approach--a significant improvement over "spaghetti code" which was difficult to debug and maintain. Nevertheless, several drawbacks to structured programming remain, such as the "semantic gap" between the concepts and entities in the world being modeled by the program and the concepts in the programming language, the textual nature of the program code, and limitations on reusability of code modules.
Eventually, a new programming paradigm was developed, referred to as object-oriented programming. In this technique, instead of defining functions, "objects" are defined (by defining their "class"). Only the external interfaces of the objects and what can be done with the objects are specified for the end-user, as opposed to the internals of they are constructed.
As a simplistic example of this technique of describing the external "appearance" of an object without the necessity of describing what it "looks like" or "does" inside, and in order to illustrate the significant benefits of such object-oriented programming, one might imagine, by analogy, a common household toaster, which could be modeled by the object-oriented approach. The external "interface" would consist of the knob, which essentially represents a parameter for adjusting the desired lightness or darkness of the toast, the slot into which the bread is inserted, and a lever for effecting the insertion and activating the toaster. The important concept is that the end-user of such an appliance does not need to know the "internals" of the toaster in order to use it, e.g. whether heat is provided by electricity, or by chemical or other means. All the user would have to do is interface properly with these externals.
The beauty of this evolution in programming is that, continuing with the analogy, the designer of the object, which might be a module of programming code modeling a toaster, may focus on improving the internals of the toaster, making it more efficient, for example, without affecting the user's ability to use the object, inasmuch as the internals are transparent to the user. Thus, more abstractly, object-oriented technology may be seen essentially as providing the advantage of separation of the interface of an object from it implementation. In a software context, the internals of the object may thereby be rewritten and improved without the necessity of rewriting the entire application program, as long as the external "knobs" etc, and their expected behavior have not changed.
The foregoing illustrates one of two important characteristics of object-oriented technology, namely, that of "encapsulation". The other characteristic is "inheritance", whereby, broadly speaking, an object may "inherit" (or acquire) all or some of its interface or implementation from another similar object, thereby avoiding the need to duplicate the descriptions of such common characteristics. For example, a "WheeledCarrier" class of objects may be defined, having the generic characteristics and definitions of having wheels and being able to carry passengers. A "Car" class of objects can then be defined, which inherits part of its description from "WheeledCarrier". Similarly, an "Airplane" class of objects can also be defined, which inherits from "WheeledCarrier". (In object-oriented terminology, the "Car" class is a subclass of the "WheeledCarrier" class, "Airplane" is a subclass of "WheeledCarrier", and "WheeledCarrier" is a superclass of "Car" and of "Airplane". Of course, cars are different from airplanes and their full descriptions will reflect the differences, but because of the use of inheritance, redundant description of their common characteristics of having wheels and being able to carry passengers is avoided.
For further general background regarding object technology to facilitate a better understanding of the invention, reference should be made to "Object Oriented Technology--A Manager's Guide", by David A. Taylor, copyright 1990, Servio Corporation.
With the development of object-oriented programming, several "object models" were further refined and developed, which specified the manner in which one was to define objects and their external interfaces, such various object models providing the aforementioned characteristics of encapsulation and inheritance among others. At an appropriately high level, these various object models are very similar, examples of which are the System Object Model (SOM), Common Lisp Object System (CLOS), Smalltalk, and C++. In essence, these various object models are simply a body of rules answering the question of what an object is, each offering slightly different answers when examined at lower levels. For example, various object models differ in their language syntax, and in how encapsulation and inheritance work.
As a direct result of these differences, one problem presented by the availability of different object-oriented languages and object models was that problems in interlanguage operability appeared, e.g. object programs could not be written with a mixture of such languages, thereby adversely impacting one of the major promises of object technology, namely reusability of code. In an effort to address this problem plaguing the industry, a Common Object Request Broker Architecture (CORBA) was arrived at by committee, which included a standardized Interface Definition Language (IDL). There was in essence an agreement in the industry as to how interfaces of an object would be specified, i.e. a standard for defining object interfaces so that objects defined by one vendor could be utilized by another. Thus, with CORBA, the effort was started to facilitate uniform definitions across languages of what an object was to "look like" in order to facilitate implementation of applications in multiple languages.
The aforementioned System Object Model (SOM) is one object model which conforms to CORBA and IDL. Conformance means that SOM objects follow CORBA semantics, and SOM objects are defined in IDL syntax. The significance of the foregoing will become readily apparent hereinafter in a more detailed description of the invention but is provided at this point for background.
We will now turn more specifically to an application of this object technology, in particular, to problems associated therewith which have plagued the industry and been successfully addressed by the subject invention. One important use of object technology is in implementing an improved "visual builder" environment for visual programming. A visual builder is essentially an application writing tool permitting the "writing" of programs visually (instead of by the more traditional method of writing textual code). Particular utility for such tools arises with respect to the writing of programs having graphical user interfaces ("GUIs"). As will be hereinafter seen, the invention provides such a program-writing tool which is itself visually based as well.
It is a characteristic of current programming technique that a great deal of the time is spent in coding the actual graphical user interface or "GUI" presented to the user (as opposed to the underlying code and functionality to which the GUI interfaces), and the present invention is directed in part to simplifying these tasks. To be more clear as to what is meant by a "visual builder", put simplistically, it is a tool which facilitates the writing of programs by the creation, movement, and interconnection of icons, e.g., through a user interface or GUI as opposed to through conventional textual programming.
A simple example of such a visual builder may be seen in the product "Visual Basic" by Microsoft Corporation in which the user interfaces, such as various windows, pull-down menus, buttons, scroll bars, and the like are created visually. A visual builder system arranges for the actual functioning interface to appear when the built application is executed, thereby relieving the programmer of the task of writing a textual program to implement the interface. As will become more apparent hereinafter, there is an increasing need to facilitate the ability to efficiently program applications visually, e.g. by "visual programmers" who do not have the detailed knowledge of computer programming languages and the like associated with the more traditional notion of a computer programmer. This need has been fueled in part by the phenomenal increase in multimedia. The invention is intended to address in part the problems associated with this concept of visual programming.
A major task of implementing a useful visual builder is to provide the function of a visual editor of the tree or graph structure of FIG. 4 (although as will hereinafter be seen it will necessarily have additional requirements, such as providing the ability to edit properties associated with the objects, etc.).
In order to more fully understand the invention, again, by way of background, a general description of the requirements for such a visual builder will now be provided.
Referring first to FIG. 2, a representative user interface 40 is shown which might appear on the monitor 38 of FIG. 1 during the process of a user visually programming a desired application. The purpose of the interface is to provide a dialog and interface between the computer and the programmer by means of visual items such as sliders, buttons, etc. whereby the programmer may proceed to structure, build, and define an end-user application. The application itself may also include graphical user interfaces employing items similar to those shown in the application build tool screen of FIG. 2, e.g., sliders, buttons, windows and the like.
More specifically, a representative interface 40 might include various icons such as slider bars 42, 46 (with associated slider "thumbs", 43, 49; end buttons 41, 45, 47, 48); buttons 50, 58; icons such as speaker icon 44; windows 52, 56; and pull-down menus 54.
One aspect of the interface 40 of FIG. 2 not intuitively obvious is that although these various items appear "flat", "under the covers" they would reveal an associated nested hierarchy of visual objects such as depicted in FIGS. 3 and 4. Thus, comparing FIGS. 2 and 3, it will be seen for example that button 58, rather than being merely a "flat" arrangement as a control, exhibits a nested relationship whereby button 58 is, hierarchically speaking, in box 56 which is in turn in box 52 and in turn in box 49.
A conventional way in the art to represent a nesting or containment relationship, such as that embodied in a GUI and the corresponding programming code implementing it, is by means of a data structure commonly known as a "tree" or graph shown in FIG. 4, which obviously more readily visually depicts the hierarchy. Each of the icons, slider bars, and the like are shown in FIG. 4 as a node or circle representing an "object" within the meaning of the object-oriented technology hereinbefore described.
In a conventional approach to writing user interface programs, trees similar to FIG. 4 are programmed textually. The various nodes, children to nodes, and children of children to nodes, etc. shown by the objects of FIG. 4 are typically implemented in building up the tree of FIG. 4 by coding in a high level language such as C, C++, or the like. As has already been pointed out, this process is extremely tedious, involving all of drawbacks of even high level languages including statements requiring precise arguments, syntax, semantics and the like.
Because of the foregoing, it became desirable to provide for the aforementioned "visual builders" whereby a program could be constructed which would in essence build the desired runtime trees of FIG. 4 by means of interactively creating, moving, and interconnecting various icons and the like (such as those depicted in FIG. 2) inasmuch as it is far easier to do so by this means rather than by writing C programs, for example.
Thus, in response to this need, vendors set upon the task of providing visual builders to interactively build up these containment structures or trees.
It should be noted that interacting with the various items of FIG. 2 would not necessarily impact the runtime tree of FIG. 4. For example, clicking on button 58 would not necessarily alter the tree structure of FIG. 4. However, moving button 58 out of box 56 to location 60 would change the hierarchical structure of this object, as may be seen in FIG. 4. Object 58A which extended from object 56A (corresponding to button 58 being contained within box 56) would, after the button 58 was moved to location 60, be reflected in the tree as object 60A now extending from object 52A (thereby reflecting the new hierarchy in which button 58 at location 60 is contained by box 52). Thus, in general, it may be seen that manipulating the items in the interface FIG. 2 may alter the corresponding object tree of FIG. 4.
A major task of implementing a useful visual builder is to provide the function of a visual editor of the tree or graph structure of FIG. 4 (although as will hereinafter be seen it will necessarily have additional requirements, such as providing the ability to edit properties associated with the objects, etc.).
Continuing with the general background discussion regarding the requirements of implementing visual builders and user interfaces, textual programming of GUI applications, for example, with the C language and some library such as X and OSF/Motif, or the Presentation Manager library of the OS/2 operating system shows that several further tasks are required beyond the building of the initial tree. The initial properties of the various nodes in the tree must be set, or, in general, the programmer must decide, for each available property, whether to specify its initial value or to accept the default initial value. (Examples of properties of the nodes in the interface of FIG. 2 would be the color of box 49, initial position of a slider thumb 43, contents of a pull-down menu 54, etc.). In addition to the task of setting or defaulting such properties of objects, there is the further task of making connections between the objects, thereby specifying the actions to be performed when certain events occur. For example, if the user were to depress button 50, the desired action might be, for example, a beeping of speaker 44. If the position of slider 43 changed, the desired action might be for some window to scroll appropriately.
Finally, after the tree has been built, the various object properties have been set, and the actions to be performed on specified events have been specified, the last task that a GUI application (either built by a visual builder or textually programmed) must do is to enter an event loop at runtime. If an event occurs, the program will perform the corresponding action, and then wait for occurrence of the next event. The typical desired behavior is for the application program to be running in an infinite event loop, responding to events such as the activation of button 50, etc.
From the foregoing, it will be readily appreciated, in summary, that a user interface application may be represented by a tree such as that of FIG. 4 which in turn represents a hierarchy of objects, and that the construction of such a tree textually is an extremely tedious matter, giving rise to the development of visual builders. However, even with the presence of visual builders, several serious problems nevertheless persisted.
First, these objects themselves (such as those shown at the nodes in FIG. 4), are typically written in accordance with more traditional programming techniques wherein the objects might never have been intended to be manipulated in a visual builder environment, but rather, intended to be part of a low level object-oriented toolkit library. Consequently, usability of these objects for higher level visual programmers may not have been a prime consideration or even a consideration at all in implementing these objects, and accordingly the properties thereof, prior to the invention, might not appear intuitive to a visual programmer.
A problem is that, in present systems, the interfaces of the runtime objects presented to the visual programmer are constrained to be those specified by the object definition. Thus present systems are limited to presenting to the visual programmer exactly the same interface (e.g., Smalltalk methods, CLOS generic functions, and by extension to CORBA, IDL attributes and operations specified by the definition of the object). Such interface may include, for example, unwieldy attribute or operation names, and attributes or operations which are at such a low level as to seriously impair the user friendliness of a visual builder.
The invention disclosed is our co-pending patent application Ser. No. 08/357,834, entitled "SYSTEM AND METHOD FOR PROVIDING A VISUAL APPLICATION BUILDER FRAMEWORK" filed on Dec. 16, 1994, solved these problems and provided a visual builder wherein the object's interface as seen by a builder user could be decoupled from that specified by the object model interface.
More particularly, it provided for an arbitrary mapping of more intuitive properties and operations of objects to the attributes and operations of runtime objects dictated by the particular object model. More control was provided in the manner in which editable properties and operations of runtime objects were presented to the visual builder user to avoid overwhelming the visual programming with unnecessary object detailing. The invention facilitated the definition of new properties of objects at higher levels of abstraction presented to the visual builder user, thereby making the editable runtime objects more intuitive.
The foregoing was accomplished by providing "proxy objects" and a system and method for visually constructing and editing a proxy object tree. Each such proxy object in the proxy object tree at build time corresponded to a correlative target object in a corresponding run time target object tree.
The proxy object interfaces, as seen by the visual builder, were "decoupled" from the interface specified by the particular object model of the target objects. In this manner, since the proxy object could be customized, the visual builder system was not forced to present to the user the exact attributes and operations of the target objects dictated by a given object model.
These proxy objects each required a great deal of information such as the class of the target object corresponding to the proxy object, presentation information on how the proxy object should present itself to the user, properties of the particular proxy object and how they are mapped to IDL attributes, and the like, all of which are further described herein.
A serious problem presented in implementing a visual builder employing the thus-described proxy object concept was how to efficiently and effectively store and access this large volume of proxy object information.
One approach was to hardcode in the implementation of the actual of the proxy itself all the necessary information for each proxy object.
Whereas this has the specific performance advantages typically associated with hardcoding, several serious disadvantages were nevertheless present as well, also associated with the nature of hardcoding.
One such disadvantage is that alteration in these proxy objects required altering the source code implementing the proxy object, which required a programmer well versed in the intricacies of writing program code.
Yet another significant disadvantage was that these changes to source code necessitated resultant recompilation of the source code.